Shareware Grab Bag

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Grab Bag / Shareware Grab Bag.iso / 013 / files.arc / OFFER_#1.TXT < prev next >

Wrap

Text File | 1987-07-15 | 18.1 KB | 393 lines

July 87 GETTING DOS TO OPEN 256 FILES SIMULTANEOUSLY!! TSR Programs, Source Code, Tutorial, Commentary and More... by Steve Gibson -*- -*- -*- This file is divided into the following sections: --------------------------------------------------- o WHAT'S ON THE DISK o USING THE NEW "FILES" COMMAND o A BRIEF HISTORY OF THIS OFFER DISK o HOW THE PROGRAMS WORK o THE WRAP UP --------------------------------------------------- WHAT'S ON THE DISK ---------------------------------------------------------------------- o FILES.TXT - This file (the one you're reading now) describes the contents of this "Steve's TSR Offer #1" diskette, and outlines the use and operation of the included files and programs. o TSR.TXT - This file is a complete tutorial introduction to the technology and operation of Terminate and Stay Resident (TSR) programs under MS/PC-DOS. It was rewritten from Steve's original four-part InfoWorld TECHTALK column series on TSR Technology. o Three SUB-DIRECTORIES: FILES33, FILES3X, and OPENER. Each sub-directory contains the collection of files pertaining to the COM file bearing the sub-directory's name. See the details which follow below: o FILES33 is for use with DOS 3.3. It was the first of these programs to be written. It "plays by the rules" by using only fully documented techniques (well almost). It also uses and demonstrates the new handle requesting mechanism in DOS 3.3. o FILES3X is for use with all DOS 3.x versions EXCEPT the latest 3.3. It uses a collection of undocumented (but well known) techniques to achieve the same effect as the DOS 3.3 handle count request mechanism. As such it allows users of DOS versions 3.00 thru 3.20 to have the same 256 file limit as FILES33.COM gives to DOS 3.30 users. o OPENER is a test program which easily and quickly demonstrates the working of the other programs. It rapidly creates and opens files whose names take the form !AAAA, !AAAB, !AAAC, !AAAD, etc. It continues in this fashion, alphabetically advancing the file names until the file creation request fails. While doing this, it counts the number of open files and displays their names and handle IDs. o RAM.COM - A "quickie" DOS command which displays the amount of RAM currently available to a DOS application program. It is useful if given before and after loading any resident TSR program (like the FILES command) to see how much memory that program consumes. It can ALSO be used IMMEDIATELY after booting DOS with various settings of the "FILES=xxx" line in CONFIG.SYS to show how much RAM is always being consumed by DOS's static file management buffers. To assist assembly language programmers who haven't yet conquered the mysteries of resident software programming, for those who wonder what assembly language programs look like, and to completely document the programs, this disk also includes heavily commented source code which takes a mild tutorial approach. Additionally, BATCH files are included which can be used to drive the creation of COM files from the included assembly language sources. As mentioned above, the three subdirectories on the diskette (FILES33, FILES3X, and OPENER) contain the files relating to each COM program. ---------------------------- PLEASE NOTE: ---------------------------- You should ONLY use ONE of the two FILES programs (FILES3X or FILES33) depending upon the version of DOS you're currently running. ---------------------------------------------------------------------- -*- -*- -*- USING THE NEW "FILES" COMMAND ---------------------------------------------------------------------- The following are step-by-step instructions are for those who want to "get on with it" and perhaps read the rest of this OFFER_#1 file later. The balance of this document contains a brief history of the programs and a complete functional and operational description of this package. If you follow the instructions below you need NOT bother reading further. FILES INSTRUCTIONS ---------------------------------------------------------------------- 0. If you are NOT using a version 3 of MS-DOS or PC-DOS (DOS 3.00 thru DOS 3.30) you MUST FIRST upgrade yourself. NONE of the programs on this disk (except OPENER which won't be of much use to you in any case) will run under pre-3.00 DOS versions. 1. COPY either FILES3X.COM or FILES33.COM from the appropriate diskette sub-directory to your main working DOS command directory RENAMING it to FILES.COM in the process. If you ARE NOT USING DOS version 3.3, copy the FILES3X.COM program. ONLY IF you ARE USING DOS 3.3, copy the FILES33.COM program. NOTE: The two programs could have easily been integrated into one, but they were deliberately individualized to allow their individual functionality to be seen more clearly. This also minimized the programs' resident portions (which is always a good thing). 2. COPY OPENER.COM from the diskette's OPENER sub-directory to your working DOS command directory. 3. EDIT your current CONFIG.SYS file changing the "FILES=xxx" line of that file (or adding one if you don't already have one) to reflect the new total number of files you'd like to be able to have open simultaneously. Values of up to "FILES=255" are acceptable. 4. REBOOT your computer to activate the new CONFIG.SYS file spec. 5. CREATE a new sub-directory on a diskette or hard disk and make it the current directory. This will be a place for experimenting with these commands which create and open MANY files. NOTE: The root directories of most floppy disks is not large enough to hold as many files as you'll now be able to create and open, and you wouldn't want the root directory of your hard disk junked up with temporary files. So do *EVERYTHING* in this sub-directory! 6. NOW, without first running FILES.COM, simply give the command OPENER. "Opener" will create files whose alphabetically sequential names take the form: !AAAA, !AAAB, !AAAC, etc. The screen will display the number, name, and DOS handle (which you can ignore if you're not into programming) as each file is created and opened. It will STOP as soon as DOS refuses to Create or Open a file for any reason. IMPORTANT NOTE: OPENER leaves these zero-length files in your sub- directory after it finishes! This allows you to easily compare the time required for many files to be Created versus Opened. Users of DOS 3.30 can also measure the benefits of DOS's new FASTOPEN resident utility in this fashion. TO DELETE THESE FILES: Give the command "DEL !AA*" which removes all files of the form: !AAxx which OPENER creates. 7. NOW, give the command "FILES". A short message will print to the screen and the DOS prompt will be returned. BEFORE DOING ANYTHING ELSE, give the OPENER command again. If everything goes as planned, the number of files you have requested in the FILES= line of CONFIG.SYS will be Created and/or Opened. NOTE: A few files FEWER than the number you requested with CONFIG.SYS will probably actually be opened by OPENER owing to the several file handles (for standard console Input and Output) which DOS "pre-opens" for application software. ALSO: The statement generated when FILES is installed may be silenced by putting any argument AFTER the FILES command. So saying something like "FILES Shhhh" will keep FILES quiet. This may be useful in various BATCH file applications. 8. The included 89-byte "RAM" command displays the amount of main RAM memory available to any application program (such as itself at the time). This is the same number returned by the DOS CHKDSK command but is much faster. It can be issued at various times to see what's where. For example issue the RAM command BEFORE the FILES command and then IMMEDIATELY afterward. Then subtract the results to see exactly how much memory FILES uses. Also, giving the RAM command again AFTER running OPENER will show that the original amount of memory available is again available, demonstrating that FILES has successfully removed itself from memory after helping OPENER to open many files. (I like that spontaneous self removal) TIPS USING FILES.COM ---------------------------------------------------------------------- As explained in further detail below, FILES.COM "goes resident" when run. It can then be thought of as "TRIGGERING" the instant ANY program either CREATES or OPENS a file. At the time of this triggering, it does things on behalf of whatever program caused the trigger, augmenting the maximum file handle count. It then removes itself from RAM and allows the triggering application to proceed. This behavior implies several things which need to be made clear: 1. The FILES command MUST be given EVERY TIME BEFORE an application program is run which may need simultaneous access to more than 20 files. The effect of "FILES-izing" a program ONLY LASTS until that program terminates. 2. It is important not to trigger FILES before you want its effect. Many programs which may not appear to be opening a file ... might be ... so it's a good idea not to do ANYTHING between running FILES and running the subject application. -*- -*- -*- A BRIEF HISTORY OF THIS OFFER DISK... ---------------------------------------------------------------------- I didn't know what I was getting into when it all began..... A cover story in the May 18th issue of InfoWorld titled "DOS 3.3 Users Report Hard Drive Problems" caught my eye. At the time, I was just finishing up the development of a new, extremely complex and exciting hard disk utility (written in 100% assembly code, the source code files for it total 340K Bytes!) so I was attuned to issues relating to hard disk problems, and decided to find out what was going on. I spoke to the various people who were referenced in the story, explaining my connection to them as InfoWorld's TECHTALK columnist. Aside from satisfying my innate curiosity about this, I thought that there might be a "column" in all this as well. The main issue raised in InfoWorld's story was that programs running under DOS 3.3 were *NOT* able to have more than 20 files open simultaneously, just as in all prior versions of DOS. This seemed strange because one of the often mentioned enhancements to the new DOS 3.3 was supposed to be the raising of that limit to "256 files per process". IBM became involved in the dialogue when the story appeared, and upon questioning, indicated that programs needed to be REWRITTEN SPECIFICALLY to take advantage of this new feature. Such programs must deliberately request access to more file "handles" using a new internal programming function available for the first time in DOS 3.3. IBM indicated that all existing DOS programs still aren't able to open more than 20 files because they don't know to ask for more handles using this new provision. The new DOS 3.3 Technical Reference Manual makes this all very clear as well, indicating that programs requesting additional file handles must first free-up some of their own RAM space for DOS' use while fulfilling the program's request. Clearly, real preparation and reprogramming is necessary even under this new DOS 3.3 As always, the "FILES=" statement in the CONFIG.SYS file is the UPPER LIMIT on the number of files which may be simultaneously open. If IBM had set FILES= to be the default, or had created another CONFIG.SYS parameter to set a "per program default" other than 20, then everything would have been just fine. But that's not the way it happened. So I started thinking about various ways to solve this problem using TSR resident software techniques. This collection of files is the result of that thinking. -*- -*- -*- HOW THE PROGRAMS WORK ---------------------------------------------------------------------- Whether we're using "FILES" under DOS 3.3 or an earlier version of DOS 3.x, several things are necessary... Requests must be sent to DOS (requesting more handles) *DURING* the time that the application program is running. This is necessary so that DOS will believe that it is the APPLICATION PROGRAM (not us) which is issuing those requests. Also, a block of free RAM has to be available to the operating system when these requests are received by DOS. The technologies of resident software easily fulfills these requirements. Application programs always receive ALL of the main memory the system has available. This memory region extends from their loading location (the program's load point) up to the end of memory. (Please see the file TSR.TXT included on this diskette for TSR operation details) We grab a block of memory BEFORE the application program begins running, then release it just before making the "more handles please" request to DOS. This way we're assured of having at least that amount of memory available to DOS when needed. The whole scheme comes together when we link into DOS' standard Interrupt 21h calling sequence. This allows our program to monitor the running application programs's use of DOS *AFTER* it has begun operating. This monitoring connection allows us to gain control and intercede whenever our program decides it's necessary. --- --- --- So now let's follow the entire sequence step-by-step... We begin by issuing the FILES command. ------------------------------------------------------------ NOTE: Depending upon your current version of DOS, either FILES33.COM or FILES3X.COM should be renamed to FILES.COM. ------------------------------------------------------------ FILES.COM runs, grabbing a small, 256-byte block of RAM memory and linking itself into the interrupt 21h chain. "Linking into the chain" means that whenever a subsequent program makes a request of DOS via Interrupt 21h, OUR PROGRAM will receive control BEFORE DOS. Once we're linked in and setup, we ask DOS to terminate us with a "TSR" call to DOS, which asks DOS to allow us to remain resident in memory. At this point we're lying dormant in RAM. We're watching all DOS activity via our Interrupt 21h (Int 21) monitoring, but otherwise we're asleep. We're waiting for any program to either CREATE or OPEN a file, at which point we spring into action. When the CREATE or OPEN occurs, we temporarily suspend that action. Then we release the block of memory which was allocated by the transient portion of the TSR program when we were going resident. DOS will find it and use it for maintaining the extended file handles table. Then *WE*, in the guise of the application program, ask DOS to extend the file handle count limit. DOS does not knowing that this request is not originating from the application program, so it complies. DOS searches through memory looking for a chunk of free RAM, finds our recently freed up block, and uses this memory to hold the additional handles we've just requested. Since we have now finished doing everything we were here for, we free up our own allocation of TSR memory, remove ourselves from the Interrupt 21h monitoring chain, and exit by passing the application's original request through to DOS. ---------------------------------------------------------------------- For assembly language programmers, the included and highly (overly) commented source code contains the next level of detail on the operation of these programs. ---------------------------------------------------------------------- THE WRAP UP ---------------------------------------------------------------------- o Well, I can't imagine anything I didn't say. (You probably can't either!) o I hope you have found this package to be interesting, informative, useful, and perhaps a bit educational. o If you're interested in a more general discussion of the operation of resident software, the file TSR.TXT is included here to provide additional TSR background information. It was rewritten from a four-column series produced for my InfoWorld TECHTALK column. o If you didn't receive this diskette (or the files) directly from my company, Gibson Research Corp., and you'd like to keep track of our progress, developments, and future offers of this kind please feel free to call with your name and address, or drop us a note or card with it. We'll be pleased to add you to our general mailing list for all future offers and info. Please phone or send your name and address to: ---------------------------------------------------------------------- GIBSON RESEARCH CORPORATION BOX 6024 IRVINE, CA 92716 (714) 854-1520 ---------------------------------------------------------------------- Finally, thanks for your interest in this package! Remember, it's in the PUBLIC DOMAIN and may be freely distributed, copied, uploaded, downloaded, etc. PLEASE KEEP THE FILES TOGETHER AND IN THEIR ORIGINAL CONDITION. Steve Gibson, President GIBSON RESEARCH CORP. <<< END OF FILE >>>